Welcome to Maurits Lamers and Mitch Oliver

written by tkeating

Hot on the heels of last week’s introduction of five new team members, I’m pleased to announce that Maurits Lamers and Mitch Oliver have also signed on as SproutCore Committers. As with the people from my previous post, these names should be of no surprise to anyone who has been with SproutCore for some time.

For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get another Reviewer’s feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.

As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and sproutcore@googlegroups.com and show them your support.

Welcome to SproutCore’s newest Committers and Reviewer

written by tkeating

As noted in the previous post, we are in the beginning of a major new thrust in SproutCore development and community involvement. As part of this work, we’ve created a guideline to becoming a contributor and list of contributors.

Today, I’m pleased to announce that several people have already graciously accepted the offer to take on roles and contribute even more towards shaping the future of SproutCore as the best application development framework, period.

Please join me in welcoming:

Jason Dooley, Jeff Pittman, Tim Evans, and Wesley Workman

as the first SproutCore Committers and

Geoffrey Donaldson

as a new SproutCore Reviewer.

Undoubtedly, you will have come across these individuals on IRC and the mailing lists and will recognize them for their commitment to SproutCore and to the community. We are very excited and lucky to have them onboard.

In the future I expect to write many more posts like this, so to those that wish to be included, keep contributing, keep learning and we hope to hear from you soon.

Changes to SproutCore

written by cjolley

Today I am writing to announce three important changes to the SproutCore project to better accomodate the community who are using it.

Change 1: SproutCore 2.0 Is Now Amber

SproutCore 2.0 started out as a rebuild of SproutCore around a more modular and modern design. Since then, the project has evolved in a different direction that means it will never be a complete replacement for SproutCore 1.x.

Therefore, we have decided to rename SproutCore 2.0 and manage it as a separate project. The new project will take on the original code name - Amber. It will be run by Yehuda Katz, Tom Dale, and Peter Wagenet.

The Amber guys are working on a new website and complete update for the new project. When they are ready we will post a link to the blog here so you can find out more about it. In the meantime, work on this project is continuing in the sproutcore20 repository on Github.

Change 2: New Contributor Process

With the Amber change, SproutCore will now once again be the sole domain of those wanting to create fast, native style applications on the web based on the SproutCore 1.x code base.

There is a very active community of developers who have invested heavily in this area. But, due to the structure of our governance system (via a Core Team), we haven’t done a very good job at making it easy for members of the community to get actively involved.

As of today we are adopting a new contributor process that will change all of this. The new process is based on the Reviewer/Committer model used by WebKit and several other big projects. It is fully documented on the SproutCore wiki, but here are the highlights:

  • All SproutCore projects will have reviewers and committers. Reviewers have the authority to approve changes to the code, committers can commit code when it is approved by a reviewer.

  • Anyone can become a committer once they have had a few patches accepted and a reviewer is willing to sponsor them. Anyone can become a reviewer once they have experience as a committer and the majority of other reviewers votes to approve them.

  • There is no longer a “Core Team”. Instead, we expect reviewers and committers to agree as a group on directional changes to the project. All discussions will be held on the sproutcore-dev mailing list or in IRC. We will avoid private mailing lists.

The goal is to make it possible for anyone who is willing to put in the time and effort to contribute to SproutCore to become a leader in the community. You don’t need a secret handshake to get in - just contribute.

To get this process started, we have identified a group of people - both former Core Team members and others - who qualify as either Committers or Reviewers and reached out to them. You can see the list of those who have already accepted on the wiki. If you aren’t on the list and you want to be, please email Tyler Keating and he will help you out.

Change 3: New Leadership

Finally, I want to talk a bit about my own role in SproutCore. Over the last year, my job has evolved to include a lot less coding and more other activities. While I am still very passionate about seeing SproutCore grow, I am not able to provide the kind of detailed attention that the project needs on a day-to-day level.

Part of the solution to this is to move towards the community driven contributor process above so that no one person can be a bottleneck anymore. We also need someone who has shown dedication to the community to help lead the process.

Tyler Keating is an independent developer who has been contributing to SproutCore for the last four years. He has shown dedication to the project and a desire to get others involved that is just what SproutCore needs.

Therefore, Tyler has agreed to become the new administrator for SproutCore. He is the main guy you should now contact with questions about managing the project day to day. I am going to remain as an honorary project owner so I can chime in on directional things.  In general though, I hope SproutCore can become more community directed than it has been in the past.  Tyler is here to help facilitate that.

Open source is only as strong as the community around it. I have been proud to get to work with some of the best technical talent on the planet through SproutCore. Thank you everyone for your contributions over the last several years.

SproutCore exists to serve your needs. Get involved and make it your own!

PS. I am posting a similar version of this post to the SproutCore mailing list where we can discuss this in the open.  Please feel free to join in there.

Why Handlebars?

written by tdale

UPDATE:

**The following post refers to SproutCore 2.0, which has split off as a separate project. However, the information within this post is entirely applicable with respect to using SC.TemplateView and Handlebars in SproutCore 1.8. If you wish to use SC.TemplateView in SproutCore, you only need be aware that the many views and controls in the Desktop framework may contain templates, but should not themselves be contained within templates.**

When people check out SproutCore 2.0 for the first time, one question that they frequently ask is: Do I have to use Handlebars?

Handlebars, if you’re not familiar with it, is a semantic templating language written entirely in JavaScript. It’s an expressive language with a tag syntax reminiscent of HTML, except expressions (oftentimes referred to as “mustaches”) are wrapped in double-curly braces. A simple template might look like this:

<div class="entry">
  <h1>{{title}}</h1>
  <div class="body">
    {{body}}
  </div>
</div>

Handlebars, unlike other templating solutions like Eco, doesn’t tempt you to embed domain logic in your HTML. Anything other than simple conditionals and loops must be contained in your application’s JavaScript, which enforces the separation of concerns and leads to better testability. The language is also extensible with custom helpers, which allows you to effectively write a template DSL for your particular application.

So, while the answer to the question is_ use whatever templating system you’d like,_ we think Handlebars is a great option. Perhaps most importantly, we’ve spent a lot of time deeply integrating SproutCore and Handlebars, such that you get a lot for free just by using bindings, computed properties, and the SproutCore object system. In fact, while we like the features and simple-yet-expressive syntax of Handlebars, the real reason we chose it when creating SproutCore 2.0 was because of its speed and architecture, allowing us the kind of integration that would be very difficult with other templating libraries. Handlebars compiles a given template only once. After that, it generates a JavaScript function that can be executed repeatedly without the expense of re-parsing the template. For example, a template like this:

{{#if arrived}}
	Hello,
{{else}}
	Goodbye,
{{/if}}
{{name}}!

might be translated into a function like this:

function() {
  var arrived = this.arrived,
      name = this.name,
      result = '';

  if (arrived) {
    result += "Hello, ";
  } else {
    result += "Goodbye, ";
  }

  result += name+"!";

  return result;
}

(Please note that the generated code looks different; this is just illustrative of the effect.)

Because you declare your intent, Handlebars knows how to generate the JavaScript that gets executed at runtime. If your templates don’t change, you can precompile the templates into JavaScript during the build process for additional speed and file size improvements. It also means that, as Handlebars is optimized, so is your application.

But most importantly, because of its declarative nature, we can make your templates bindings-aware. Here’s where the real advantage appears: you never have to write code that updates the DOM. Most other frameworks require you to have two separate code paths: one that creates the initial representation (often via a templating solution), and one to update it, usually with something like:

$('#welcome').text("Goodbye, "+this.name);

With SproutCore and Handlebars, both behaviors are contained in the same template.

But beyond simple values, we also support things like conditionals and loops. If you use the {{#each}} helper to print an array, for example, the DOM will update automatically whenever items are added, removed, or modified. This eliminates lots of boilerplate and common bugs from your application, and it means you don’t need to anticipate all of the places data may change and manually re-render. Just modify the array (or the contents of the array) and let Handlebars take care of the rest.

So, while we encourage you to use whatever templating system makes most sense to you, we think that using the built-in Handlebars integration will let you write less code–and have fewer bugs–by eliminating the tedious boilerplate that you’re used to writing.

You can expect many improvements to these auto-updating templates as time goes on. In particular, we are focused on ensuring they work flawlessly with elements, such as <tr>, that have strict requirements about their enclosing tag. Yehuda and I have been working on metamorph.js, which we are in the process of integrating into SproutCore 2.0, that will both improve compatibility with these kinds of elements, as well as offer performance improvements. Look for these commits to SproutCore soon!

Hubbub ❤ SproutCore - Socket.IO & Modular Loading

written by tkeating

As promised in my last post, I’ll go into more detail on some of the technical aspects of Hubbub. And since there was only a single request to talk about Socket.IO integration with SproutCore, that’s the topic for today. In order to keep these posts down to a nice bite-sized length, today will strictly be about how Hubbub uses SproutCore’s modular loading to include Socket.IO.

Socket.IO! I Choose You.

There is actually some nice stuff that happens in Hubbub in real time if you have the app open. For example, if someone sends you a message, signs out an item to you, makes a new item available, or any number of other events occur, then the application updates instantly without requiring a page reload. Sure it’s not new, but with Socket.IO and SproutCore it’s also not a difficult-to-implement kludge.

So for those that haven’t yet tried it, Socket.IO is available here. There are really good instructions on using Socket.IO on their site, but it’s so simple I will include my entire setup here.

My Setup - Server Side

Hubbub’s app server is written with Node and Express. So after installing Socket.IO, there’s nothing more to getting it working server-side than:

app = require('express').createServer({key: …, cert: …, ca: …});
io = require('socket.io').listen(app);
app.listen(3443);

Note: I use port 3443 locally with TLS/SSL encryption, which is not strictly necessary.

My Setup - Client Side

On the client side, you need to first retrieve the Socket.IO JS from the server. Initially, I added the Socket.IO script to my copy of index.rhtml directly above the javascripts_for_client statement. This simply pulls the JavaScript from the server on page load like the Socket.IO default examples show and if you want to do the same and aren’t using a custom index.rhtml, then the instructions for copying index.rhtml are listed at the top of the original file.

However, I’m just not satisfied with Hubbub being anything less than the best application it can be, and the first improvement I made to reduce loading times was to load Socket.IO dynamically. Without getting into the details of how I use Statecharts, the application begins basically like this:

[caption id=”attachment_1839” align=”aligncenter” width=”245” caption=”Initial States Diagram”][/caption]

Notice that I don’t load Socket.IO until the application reaches the Ready state. The following details describe exactly how I’ve done this.

1. Directory Structure

To make Socket.IO available to all the apps in my Hubbub project, I wanted it to be its own framework. The relevant directory structure I used is this:

hubbub/
   frameworks/
      socket.io/
         modules/
            io/
         resources/

I then copied socket.io.min.js and WebSocketMain.swf from ./node_modules/socket.io/node_modules/socket.io-client/ into my project like so:

hubbub/
   frameworks/
      socket.io/
         modules/
            io/
               socket.io.min.js
         resources/
            WebSocketMain.swf

2. Buildfile

The files are now where I want them, but SproutCore’s build tools won’t load anything in the frameworks or modules directories unless told to do so, plus I still need to proxy the Socket.IO traffic to my local development server. Here is the relevant part of my Buildfile:

config :hubbub,
   :required => [
      :'socket.io'
   ],
   :deferred_modules => [
      :'socket.io/io'
   ]

proxy '/socket.io',
   :to => 'localhost:3443',
   :secure => true, # Hubbub is entirely over HTTPS
   :timeout => 25 # A longer timeout for polling transports

I’ve required :'socket.io' here as an example, which isn’t strictly necessary. The reason you may want to do this is so that frameworks/socket.io/resources/ will be included in the builds, and therefore if you were to use flashsocket as a transport mechanism, you would be able to set WEB_SOCKET_SWF_LOCATION = sc_static('WebSocketMain.swf'); (see the Socket.IO FAQ).

Also notice that the socket.io/io module is deferred. Therefore it won’t be fetched until we tell SC.Module to do so. That way, we can pass through our initial application states without any background loading interfering with the more important task of getting people into the app as quickly as possible.

3. Load the Code

Finally, to load Socket.IO I added the following to Hubbub’s READY state:

enterState: function() {

      // Load Socket.IO and initialize it when it is ready
      SC.Module.loadModule('socket.io/io', this, this.initializeSocketIO);

    },

    initializeSocketIO: function() {

      socket = io.connect('https://localhost:3443');

      socket.on('connect', function() {
        // ... for a later post

Cool Beans

At this point, I see the following in my development console after reaching the READY state:

SC.Module: Attempting to load 'socket.io/io'
SC.Module: Module 'socket.io/io' is not loaded, loading now.
SC.Module: Loading JavaScript file in 'socket.io/io’ -> '/static/socket.io/io/en-ca/current/javascript.js?1315847166'
SC.Module: Module 'socket.io/io' finished loading.
SC.Module: Evaluating and invoking callbacks for 'socket.io/io'.
SC.Module: Module 'socket.io/io' has completed loading, invoking callbacks.
RTM: Welcome to Hubbub Real Time Messaging

And that my friends, is that! An extra 42KB of data and processing that does not detract from the application start up. See it in action at https://hubbubapp.com . You’ll need to get one of your Borrowers online at the same time as you.